home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000084_owner-urn-ietf _Thu Nov 7 06:04:10 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25253 for urn-ietf-out; Thu, 7 Nov 1996 06:04:10 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25248 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 06:04:08 -0500
  3. Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA19965  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 06:03:44 -0500
  5. Received: from  jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C)
  6.     id AA20001; Thu, 7 Nov 96 12:08:42 +0100
  7. Received: by  jrc.it (5.x/EB-950213-L)
  8.     id AA01299; Thu, 7 Nov 1996 12:03:31 +0100
  9. Date: Thu, 7 Nov 1996 12:03:31 +0100
  10. From: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
  11. Message-Id: <9611071103.AA01299@ jrc.it>
  12. To: urn-ietf@bunyip.com
  13. Subject: [URN] Pending Messages, reboot of elec/139.191.71.138
  14. X-Sun-Charset: US-ASCII
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Pending Message: uucp/11 days, 
  21.     2 left; postmaster@jrc.it, dirkx@elec, postmaster@elec.isei.jrc.it
  22. ---
  23. Ron,
  24.  
  25. About the last URN HTTP-alike resoving
  26.  
  27.     GET <service>/<uri>  HTTP/1.0
  28.     GET N2L/cid:foo%40huh.com HTTP/1.0
  29.     GET N2L/cid:foo%40huh.com HTTP/1.1
  30.  
  31. As expressed before, I am quite unhappy with using
  32. a 'fudged' (partial) URI in the request, rather than
  33. a proper METHOD or a real different syntax easy
  34. to recognize. Althoug I now agree that the META method
  35. I was advocating in the past in nowhere near flexible
  36. enough.
  37.  
  38. If you look at the way the proxy requests and current
  39. 'full' urls in http 1.1 got squeezed in, I think we have
  40. a clear example of what a mess this gives in the long
  41. run when new protocols are added.
  42.  
  43. RFC1738->
  44.         ; HTTP
  45.         httpurl        = "http://" hostport [ "/" hpath [ "?" search ]]
  46.         hpath          = hsegment *[ "/" hsegment ]
  47.         hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
  48.         search         = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
  49.  
  50. Looking at RFC1738 I realize that the use of the
  51. '/'  before the colon and the absense of the initial '/'
  52. should perhaps give enough of a  guarantee that both a partial 
  53. is very easy, especially for proxies; and overloding such
  54. a little 'hole' in the specification for extension seems
  55. bad practice to me; the future will bring more and more
  56. proxies en-route, mixed 1.0, 1.1 and 1.x server/client
  57. combinations of different vendors. And a lot f servers are
  58. moving away from being essential unix file based into
  59. database retrival engines; for whom the bit after the '/' is
  60. just a token.
  61.  
  62. So why not really split dimensions, and make it a separate
  63. method:
  64.  
  65.         N2L, N2C or N2N, ...
  66.  
  67. I can assure you that, if this is the way to go; servers
  68. like apache can be augmentated to pass on the method, and
  69. to accept handlers for arbitrary methods. For testing
  70. purposes, there is a copy of a module in Contrib/incoming.
  71.  
  72. And while on the subject; the HTTP\/(\d+)\.(\d+) string;
  73. do we _really_ want that ? given that with the above
  74. will need an add-on. How about URNRESOLV/version.version.
  75. :-)
  76.  
  77. Dw.
  78.